This invention relates to computer mail systems, and more particularly to authentication of e-mail messages.
Electronic mail (email) is likely the most frequently used application of the global network known as the Internet. Short text messages, audio or video clips, and attached files of many different formats can be sent to remote users using email.
Emails are often used as evidence in the court of law, such as during the Microsoft Antitrust trial. Companies are now storing email messages so they can be retrieved as evidence. However, since the contents are in digital form, they can be tampered with or forged. Inventors also may wish to document inventions using email.
Unfortunately, the Internet has not escaped the notice of the more sinister elements of society. Since many email messages are digital-based, it is relatively easy to alter the contents of an email message. Even the email header such as the sender""s address or Internet Protocol (IP) routing information can be altered. Such xe2x80x98forgedxe2x80x99 email is often sent to large numbers of recipients with a false sender""s address. Such email, known as xe2x80x98Spamxe2x80x99, is often an advertisement for pornographic or xe2x80x98get-rich-quickxe2x80x99 web sites. Since the sender""s email address is forged, there is no easy way to track down the true sender. The innocent person with the sender""s address that was forged often has to suffer abusive comments or xe2x80x98flamesxe2x80x99 from recipients of the Spam email.
The growth of electronic commerce (eCommerce) over the Internet has been impeded by the ease of intercepting and forging email. For example, a vendor cannot be sure that the sender actually sent an email requesting purchase of an item. The sender""s email address in the header could have been forged. Most eCommerce today is conducted using secure web sites and browsers, such as the secure-sockets-layer (SSL) protocol that operates on top of TCP/IP. While confirmations may be sent by email, actual transactions avoid email due to the lack of security.
The security of email is increased when encryption is used. Encryption software such as Pretty-Good-Privacy (PGP) originally written by Phil Zimmerman can be installed on local personal computers (PCs) to encrypt and decrypt email. Some client email programs such as Microsoft""s Outlook allow for the exchange of digital certificates or keys for encryption. However, both the sender and the recipient""s computers must have the encryption software installed, and the encryption keys must be exchanged before the email is sent.
Encryption software such as PGP can also authenticate email messages. The message itself does not have to be encrypted. This allows the message to be viewed as clear text by someone without the PGP software. A digital signature is added to the bottom of the email message by the sender""s encryption program. The digital signature can be verified by the recipient using the PGP encryption software and an encryption key. Verifying the digital signature also verifies that the message itself was not changed, since the message is mathematically merged into the digital signature. If either the digital signature or the message body is altered, authentication produces a warning message.
FIG. 1 shows email sent over the Internet where email clients authenticate email using encryption software. Email client 14 sends an email message to remote email client 15 over Internet 10. The user of email client 14 first writes the message, then inputs the message to encryption software 16, which attaches a digital signature to the message. The message with the digital signature is then sent from email client 14 to email server 12, which routes the message over Internet 10 to email server 13. Finally the message is delivered to the inbox of remote email client 15. Email servers 12, 13 are typically on server machines of an Internet Service Provider (ISP) or corporate workgroup. Other routers, bridges, and gateways (not shown) are present on Internet 10.
The user of remote email client 15 then copies or inputs the message, with the digital signature, to encryption software 17. Encryption software 17 then uses an encryption key to verify the digital signature and the contents of the message. If the message was altered, encryption software 17 alerts the user with a warning message.
Various email authentication and Internet change-detection schemes are known. See U.S. Pat. No. 5,651,069 by Ragaway, U.S. Pat. No. 5,771,292 by Zouguan, and U.S. Pat. No. 5,898,836 by Freivald et al.
While email can be authenticated, each email client 14, 15 must have his own encryption software loaded on his local PC. Usually the same brand of encryption software (PGP, etc.) must be loaded on each PC. Since relatively few people have PGP software loaded on their PC, most users cannot authenticate PGP digital signatures. The cost of purchasing and installing PGP or other encryption software on each client PC is prohibitive.
Encryption keys must be exchanged separately from the email message, preferably before the digitally-signed email is sent. PGP uses a complementary pair of keysxe2x80x94a public and a private (secret) key. Management of the key-pairs adds unwanted complexity.
FIG. 2 shows client-side email authentication using a browser to access an email web site. Web sites or services that allow people to set up an email account that can be accessed from any machine on the Internet have become quite popular. Such email web sites are provided by HotMail, Yahoo, Excite, Juno, and others.
Rather than use a local mail server, the user of browser 24 uses email web site 20. The user types text into an input box displayed on browser 24, which is directly input to web site 20 using hyper-text-transfer protocol (HTTP) packets rather than email. Messages are stored at web site 20 in an inbox or sent folders on storage 22. These messages are sent from email web site 20 over Internet 10 to mail server 13 to reach remote email client 15. Of course, email can be sent or received from other email web sites rather than from clients of local mail servers such as remote email server 13.
Although the user of browser 24 does not need email software, encryption software 16 is still needed since email web site 20 does not provide encryption services. Since the user of browser 24 may operate on many different PC""s, it is likely that the correct encryption software 16 is not present on all PC""s used. Further, the user of browser 24 may not want to leave his encryption keys on some PC""s.
Email web site 20 could provide encryption services, but most do not. Since there is often little or no verification needed to open an email account at email web site 20, verification of encryption keys and their ownership is problematic. Thus authentication using digital signatures and encryption is usually not supported by email web site 20. Encryption software 16, 17 on the client PC""s is again necessary to attach digital signatures and authenticate email.
FIG. 3A shows an email message with a digital signature. An email message is composed and input to the PGP encryption software. The recipient""s public key is used to generate a digital signature for the message. This digital signature is mathematically generated from both the public key and the message body itself. The digital signature is appended to the message between the lines xe2x80x9cxe2x80x94BEGIN PGP SIGNATURExe2x80x94xe2x80x9d and xe2x80x9cxe2x80x94END PGP SIGNATURExe2x80x94xe2x80x9d. The digital signature ensures that all the message text from the xe2x80x9cxe2x80x94BEGIN PGP SIGNED MESSAGExe2x80x94xe2x80x9d until the digital signature has not been altered.
The recipient uses his complementary private key to unlock the digital signature and check the message contents for alterations. The recipient can reply to the message, as shown in FIG. 3B. However, the recipient could alter the message text, such as to increase the agreed-upon price quote. Additional characters such as xe2x80x9c471xe2x80x9d can be added to the message body so that the authentication software can be fooled. The combination of the additional xe2x80x9c471 characters and the altered price form an alias of a checksum of the message text and thus the altered message appears to the encryption software as an unaltered message. Simpler checksum-authentication schemes can be compromised, especially when the checksum algorithm is well-known.
A problem that can occur with spell-checking is shown in FIGS. 3C-D. When the recipient replies to the digitally-signed email, a spell-checker may be used. This spell-checker may detect misspelled words in the original message. If these words are changed, then the original message may appear to be altered.
In FIG. 3C, the original message contains the misspelled word xe2x80x9cgarenteexe2x80x9d. When the spell checker is run, the misspelled word is changed to the correct spelling xe2x80x9cguaranteexe2x80x9d as shown in FIG. 3D. When the message is authenticated, a warning message is generated since the original message was inadvertently changed by the spell-checker. Other software may also alter the original message. For example, many email programs add indent characters xe2x80x9c greater than xe2x80x9d to the left margin of each line in the original message. For example, the original message:
Thanks for the info. I accept your quote for $38,702.
Is changed to:
 greater than Thanks for the info. I accept your  greater than quote for $38,702.
The indent characters alter the original message so that authentication fails. It is desirable to be able to authenticate an embedded email message that has had indent characters added to the beginning of the original message""s lines. Some tools such as Microsoft""s Outlook add formatting or hidden characters. It is desirable to authenticate these messages.
While digital signatures are useful, it may be possible to alter a message that is authenticated with a simple checksum by adding other characters to form an alias of the original checksum. A more robust checksum method is desired that uses an extra variable that is unknown to both the sender and recipient. It is desired to store the checksum and the extra variable at a secure, third-party web site so that the checksum and the extra variable are not available to the sender or recipient. It is desired to stored the checksum and the extra variable at a third-party web site such as an email web site.
It is desirable to eliminate the encryption and authentication software from the client PC""s. It is desired to locate the email authentication software on the email web site. It is desired to integrate email authentication with an email web site. A web site that authenticates email is desired. It is also desired to authenticate embedded email messages that are quoted within another email message.
An authentication service provider has an identifier (ID) generator that generates an authentication ID. The authentication ID is unique for at least a portion of an electronicmail (email) message.
A message merger receives the authentication ID from the ID generator. It inserts the authentication ID into the email message. A checksum generator generates a checksum for the email message.
A table has entries each containing a checksum. The authentication ID selects an entry in the table containing a stored checksum for the email message identified by the authentication ID. The checksum from the checksum generator is written to the table into an entry identified by the authentication ID. The checksum written to the table is a stored checksum.
An identifier (ID) extractor is coupled to scan email messages for the authentication ID. When the ID extractor finds an authentication ID in the email message, the checksum generator receives the email message and generates a new checksum for the email message.
A comparator receives the new checksum from the checksum generator and receives the stored checksum from the table. It signals a successful authentication when the new checksum matches the stored checksum from the table. A result indicator is coupled to the comparator. It signals when the comparator signals the successful authentication, but signals an altered indication when the comparator does not signal the successful authentication. Thus email messages are tagged with the authentication ID which later selects a stored checksum in the table. The stored checksum is used to signal successful authentication or alteration of the email message.
In further aspects of the invention a result marker marks the email message with the result indication from the result indicator. A random-number generator generates a random number for input to the message merger. The message merger merges the random number with the email message before input to the checksum generator. A random-number field is included in each entry in the table. The random-number generator writes the random number to the random-number field in the entry in the table selected by the authentication ID when the checksum is written to the entry.
The random number from the table is merged with the email message before the new checksum is generated by the checksum generator. The random number causes a different checksum to be generated for the email message. Thus the random number is stored with the checksum in the table, the random number being merged with the email message prior to checksum generation.
In still further aspects the random number from the table is a seed or parameter to the checksum generator. The random number is not added to email messages sent over an Internet but is only added to messages input to the checksum generator. Thus the random number is not sent over the Internet with the email message but is kept secure by the authentication service provider.
In other aspects the message merger inserts a marker into the email message. The marker contains the authentication ID. The ID extractor scans the email messages for the marker that contains the authentication ID. Thus the authentication ID is in a marker added to the email message.
In further aspects the marker contains an email address of the authentication service provider. The email address is used to return email tagged with the marker to the authentication service provider for authentication.
In other aspects the message merger inserts a copy of headers for the email message. Thus a copy of the headers for the email message is also authenticated.
In further aspects a character filter is coupled to receive the email message. It removes a target character added by an email program. The character filter sends the email message with the target characters removed to the checksum generator. Thus target characters are removed before the checksum is generated. In further aspects the target character is a quotation-indent character xe2x80x9c greater than xe2x80x9d at a beginning of a line of text.
In other aspects an email web site includes tools to compose, send, receive, and read email from the Internet. The email web site allows users to send and receive email. Email sent and received from the email web site is sent to the authentication service provider for tagging with the authentication ID and for checksum comparison for authentication before being sent to the Internet or received by users of the email web site. Thus email authentication is integrated with the email web site.